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Abstract - This paper describes a Satellite Control Reference Model that provides the basis for an 
approach to identify where standards would be beneficial in supporting space operations functions The 
backgronnd and context for the development of the model and the approach am described .A Sess hr 

tfaCe top level mter °perability directives to specific sets of engineering 
interface standards that must be implemented to meet these directives is discussed. Issues in developing 

a universal” reference model are also identified. ueveiopmg 

INTRODUCTION 

The need for a standard approach to identify where standards would be beneficial in supporting space 
operations functions has been expressed by many people in the field. 

• To show a link between the selected standard and the desired benefits of applying the standard. 

• 1 o broaden understanding and acceptance of recommended standards. 

• To permit benefits of standardization to be spread across several networks. 

™'\T an , Cl u rd .f PPr ' ,aC ! 1 10 selectin g standards”, based on a functional satellite control reference model 

anv snenT h f d !: pendent ” ; that is ’ * shouId P e ™it identification of standards needed to support 
any spec, ,c benefit such as interoperability, cost reduction, etc. Ideally this standard approach would 

apply to all space operations networks and would allow each standard to be easily tied to its supporting 
operational function and therefore the benefits could be evaluated. P 8 

The Air Force has funded the development of such a standard approach that is based on an extension of 
the approach in Vol 7 of the DoD Technical Architecture for Information Management (TAFIM) 
developed by the Defense Information Systems Agency (DISA). The approach is behig applied to the 

the rnm Ce Contro1 Network (AFSCN). Representatives from other Government agencies and 

ommercial space operations community have expressed interest in extending the initial approach by 
developing a more universal reference model as its basis. Benefits from standardization in one satellite 

definTt'oTs ^ e " be eValuated for USe in another network usi "g same functional and interface 


BASIS OF REFERENCE MODEL 

Satellite Control Systems can be defined as “A configuration of communications and data processing 

m h3t collectlveIy provlde the capability to control satellites”. Implicit in this definition is the 

orhi t^c h pckri C | SyS tem * are used ln a11 P hases of satellite control, including prelaunch, launch and early 
orbit checkout, on-orbit operations, and mission completion. Missions include weather forecast 

missile warning, navigation, and communications. Mission execution and mission data processing 

Snn a The 0 same Th “f”’ 3111,011811 the Capability t0 perfonn * ese ™ssion functions can 

de on the same subsystems as the ones used for satellite control. Process control systems are an 
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important subset of satellite control systems because their real-time characteristics drive many of the 
system performance requirements. Based on this definition of a satellite control system, it would be 
logical to use already accepted frameworks to tie standards to satellite control functions. In this paper the 
word “standard” refers to an engineering or product standard (physical/electrical interfaces, formats, 
protocols, etc.), not an operations standard (procedural or administrative). 

Information Systems Reference Model. 

The Defense Information Systems Agency/Center for Information Management has derived a TAFIM 
from the NIST Application Portability Profile and the IEEE PI 003.0 OSE models (begun in 1986). This 
architecture defines a target common conceptual framework or reference model for an information 
system infrastructure and the specific applications that the information system must support. It also 
subsumes the widely accepted Open Systems Interface (OSI) reference model within the network 
services and communications area. This architecture, and associated model, is not a specific system 
design. Rather, it establishes a common vocabulary and defines a set of services and interfaces common 
to information systems. DISA’s Information Technology Standards Guidance (ITSG) and Adopted 
Information Technology Standards (AITS) documents describe and support this architecture. The 
associated AITS identifies standards and guidelines in terms of the architecture services and interfaces. 
The architecture serves to facilitate the development of plans that will lead to interoperability between 
mission area applications, portability across mission areas and cost reductions through the use of 
common services. 

Satellite Control Reference Model. 

Operations that are unique to satellite control need to be addressed in the Mission Area Applications 
Section of the TAFIM. Therefore specific satellite control services, such as Timing (those aspects 
unique to satellite control), Tracking and Data Relay, Telemetry Processing, Command, Resource 
Control, Contact Execution, and Management were added to those in the generic information systems 
model. Network Services were also broadened in scope to include earth/space and space/space services. 
By moving the major service areas into an OSI-like reference structure, it is possible to establish a 
hierarchical “standard” framework for understanding the relationships between satellite control 
functions. Figure 1 illustrates this framework or Satellite Control Reference Model (SCRM). The 
hierarchy is based on levels of functional abstraction, from management services, down to control 
services, further down to basic computer services and finally down to network and point-to-point 
communications (layers 1 to 6). All of these unique satellite control services would operate at OSI 
Application Layer 7. Functions in layers 7b and above in the hierarchy would relate to the Mission Area 
Applications area in the TAFIM. Functions in layers 7a and below relate to information management 
systems. Note that all services are not used at each location and that these services are not dependent on 
location nor are they necessarily automated. 

STANDARDS IDENTIFICATION APPROACH 

Since the unique satellite control services are not part of core information management systems, they 
may require standards unique to the satellite control domain that are not covered in the AITS. An 
approach, based on the SCRM, is needed to accomplish this standards identification. Of special interest 
is identification of those standards that are most appropriate to reap the benefits of interoperability. 

The approach is based on describing the functional flows between each of the satellite control service 
areas in enough detail so areas where standards would be beneficial can be easily identified and existing 
standards evaluated to see if modifications/replacements are necessary to achieve the benefit desired. To 
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ThL , of functional diagrams for every satellite control service area has been developed 
These simple functional diagrams show input, output, and the basic functions provided by each service 
area. In the future we will generalize the functional descriptions related to levels 7b and above remove 
operational procedures inherent in the functional descriptions and move as many currently “unique” 
satellite control functions into the information management category (black background) as possible. q 



Rgure 1 STANDARD FRAMEWORK FOR SATELLITE CONTROL 
-Defines functions and interfaces for all services provided- 

Overview of Approach 

The specific approach which facilitates identification of the relevant standards to apply to development 
and implementation of the satellite control functions, is outlined in the following steps: 

DeSCn . be the desired beneflt of standardization for the relevant program. For each major 

matcMhe°f ntr0 “Tn "'O'" S i CRM ’ reVieW lhe baSeline functional diagrams to ensure they 
atch the funcuonal flow for the relevant program. If they need to be modified do so 

Mep 2: Based on the functional diagrams, the desired benefit, and expertise about how various 

provlded > 'deutify areas where use of standards would be beneficial, (are needed), 
and list these areas so they are tied directly to a relevant function and service area. 

VV : /° r eaCh ° f the beneficial standardization areas identified in Step 2, identify what 
standaids are currently being used and which emerging standards, if any, might be applied to that 
area to achieve the desired benefit. Coordinate with other satellite control organizations for 

nnH^Y nd feedback ’ and e " sure commonality among interested groups. List these standards 
under the appropriate standard needed” heading on the form used in Step 2 

Step 4: From the compiled information, identify what relationships exist among the standards. 

ere muhipte standards are used for the same satellite control functions, investigate the 
feasibility of joint adoption of a future common standard and devise an evolutionary path to it. 
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For functions where standards are needed but none exist or are emerging, describe how such a 
standard might be developed for the benefit of all networks. 

Example of Application of Approach to Identifying Standards, 

Figure 2 illustrates a functional diagram for the Contact Planning Services function. The primary inputs, 
subfunctions, and outputs are shown, along with a short description of how the services are to be 
accomplished to provide a context for understanding where standards might be appropriate. To increase 
interoperability, the input-output external interfaces are of primary interest. 


INPUT 


OUTPUT 


Resource Management Services 
- Twenty four hour schedule 


Platform. Pavload and Orbit/Attitude 
M^na g e m entSerylgga 
- Status and contact requirements 


Contact Planning 

• Prepare resource schedule request for 
the seven day schedule (PAP) 

• Coordinate the 24 hour schedule 

• Develop Contact Support Plans for 
contacts on the 24 hour schedule 


RejBauK&M angggmw it S ervice s 
- Resource schedule request for 
contact support (PAP) 


Contact Execution and 
Pa ylQadand. O rbLVAtt l tude 
Management Services 
- Contact Support Plans 


Description: Contact Planning Services involves the analysis of status and requirements to determine what needs to h** 
done for the SV, These SV needs are then expressed in a contact support plan (CSP) that results in an agenda for a 
scheduled contact with the SV. The CSP is then provided to Command services where it is executed under the control of 
Contact Execution Services. The resources needed for the contact are requested by Contact Planning Services through the 
PAP input to the seven day schedule prepared by Resource Management Services. 


Figure 2 CONTACT PLANNING SERVICES FUNCTIONAL DIAGRAM 


Figure 3 portrays a form used to assess where standards would be beneficial for the Contact Planning 
Services function. The form provides space for indicating what service(s) are interfaced with, the 
interfacing function, and the context (input, output, HCI) and type (Protocol/Format, 
Electrical/Mechanical/Physical) of that interface. In addition, there is space for indicating the areas where 
standards are needed and a column for indicating the current standard status, as defined in the lower part 
of the Figure. This assessment approach can then be used for each function within the Satellite Control 
Service areas to assure a level of consistency and completeness in the eventual results. 

Once areas of needed standards are identified, the status of any applicable standards can be more readily 
assessed. The assessment occurs for three time periods: currently, near term and long term. It is 
effective to record this assessment on the same form shown in Figure 3. For the Contact Planning 
function, it was noted that there is no standard format for requesting use of network resources by an 
external user. Standardization on an interface format would facilitate interoperability in scheduling and 
allocation of the network assets. 
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SATELLITE CONTROL TECHNICAL REFERENCE MODEL 
ASSESSMENT OF STANDARDS NEEDED AND AVAILABILITY 


SERVICE AREA 


FUNCTION 


CONTEXT 


STD 

STATUS' 


_WHAT TYPE OF STANDARD WOULD BE BENEFICIAL AND WHY 


STD 1993 


STD 1994-95 


I STD > 1995 


CONTACT 


PLANNING 


INPUT 


USER l/F 


OUTPUT 


NOW 

Limited 


NOW 


VOID 


VOID 


NOW 


VOID 


NOW 


Formats for expressing SV service/cortirol requirements 


AZ/EL acqusition 
format is std, 

• 24 Hour Schedule 


. None known - should be developed to reduce 
•operator training time/cbst and increase I/O 


RCC format dev. by ASTRO 
HCl/Method for generating CSPs 


• HCl/Method for 


InOOH/TO 


i » 

planning contingency responses 


♦ Format for Contact Support Plans (CSPs) 


— 7 ww rr vlt i iumo 

Existing Std. Format l(should be automatedlwhere not already done) 
• Format for resourJe request for contacl support 


Each Program has ov|n format 
Station Configuration 


Existing part of CSP 


I 9 

NOW: Standard is reasonably mature with products that are available today or expected to be 
available within 6 months. 

FUTURE: Standard is emerging and may be subject to change but is generally headed toward 
stability. 

GAP: Standard is available as temporary gap-filler. It is recommended for use only if the 

organization is willing to take a moderate investment risk because the final standard 
for the area may or may not be compatable with the gap-filler. 

VOID: No standards in the area and no known emerging one. The absence of a standard here 
may translate into significant risk for long-term planning or investment. 

UNSTABLE: Standards are emerging and rapidiy evolving. 

N/A. No standard is needed in this area. This code will be reserved for areas where at first 
glance it would appear that a standard might be useful, but further analysis shows that 
the disadvantages of standardization in this area outweigh any potential advantages. 


Figure 3 EXAMPLE ASSESSMENT OF STANDARDS NEEDED 

AND AVAILABILITY 
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FUNCTIONAL INTEROPERABILITY APPLICATION 


There have been several published definitions for “interoperability” including those in JCS Pub 1-02 and 
MIL-STD-973. According to the JCS Pub 1-02, interoperability is “The ability of systems, units or 
forces to provide services to and accept services from other systems, units or forces, and to use the 
services so exchanged to enable them to operate effectively together”. While this definition provides 
overall guidance, more specific information is needed to tie high level (ORD and CON OPS) 
interoperability requirements to specific engineering and operational consequences/benefits. One 
approach is to have overall requirement documents address “how much interoperability” is needed 
between specified programs or domains. That is, to specify the “degree” of interoperability needed. 

Degrees of Interoperability 

Figure 4 portrays the breakdown of the “Services” to be exchanged, to achieve general interoperability, 
into more specific functions as the domain of application becomes narrower. 


JCS DEFINITION 


C3 DEFINITION 


Services Exchange 


DO • Communication Exchange 


SATELLITE CONTROL 
DEFINITION 


Ground Network Comm Exchange 
Space/Ground Comm Exchange 
Space Network Comm Exchange 


STANDARDS 

• l/F standards 

• Eng. Standards/ 

processes 

• Ops. Procedures 


D1 • Command & Control 


• Platform/Resource Control & Contact Processing 

• Payload Control 


D2 • Management & Planning • Management & Planning analysis 


Figure 4 SPECIFIC DEFINITIONS FOR INTEROPERABILITY 

Moving from the General Domain to the C3 Domain, “Services” can be broken into Communication 
Exchange, Command & Control and Management and Planning Services. Moving further into the 
Satellite Control domain. Communication Exchange can be broken into 3 subsets, (Ground Network, 
Space/Ground and Space Network), because of the differences in their application environment. Each of 
these can be specified as a “degree of interoperability” in the satellite control operational environment. 
Command and Control Services can be broken down into Platform/Resource Control & Contact 
Processing and Payload Control for the Satellite Control Domain. Each of these can be specified as a 
degree of interoperability. The Platform/Resource Control & Contact Processing Degree of 
Interoperability was purposely constrained to routine processing functions and resolution of Level 1 and 
some Level 2 anomalies because these can be most readily automated and there is high likelihood that 
many programs will find it beneficial to be interoperable to this degree. The benefits of implementing 
this degree of interoperability are high, but are dependent on basic Ground Network Communication 
Exchange being available. Management and Planning Analysis services in the Satellite Control Domain 
include resolving Level 3 anomalies and require operators to be cross trained on mission and payload 
information. The benefits of this degree of interoperability are dependent on the “lower” degrees of 
interoperability being implemented first. Four of these degrees of Satellite Control interoperability are 
pictured in Figure 5. 
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SPACE/GROUND COMMUNICATION EXCHANGE INTEROPERABILITY MANAGEMENT & PLANNING ANALYSIS INTEROPERABILITY 


Figure 5 SATELLITE CONTROL DEGREES OF INTEROPERABILITY 

Mapping Degrees of Interopera b ility to Set of Standard Interfaces. 

As the degree of interoperability increases from D1 to D3, so too does the emphasis on higher levels of 
functional abstraction represented in the SCRM. As shown in Figure 6, Ground Network 
Communication Exchange Interoperability (Dl-a) is accommodated almost entirely within the lower six 
OSI layers, Platform/Resource Control and Contact Processing Interoperability (D2-a) is accommodated 
almost entirely within OSI layers 7b and 7c, while Management and Planning Analysis Interoperability 
acc ° mmodated almost entirely within OSI layers 7d and 7e. Using this correspondence the 
SCRM can be used to determine the set of interfaces that need to be standardized to support the various 
degrees of interoperability. Determination of which specific set of standards to select for standardizing 
these interfaces can then be performed for the environment of interest. The mapping from definition of 
degree of interoperability to a specific set of standards to be applied is then complete. 

CONCLUSION 

The standard framework and approach described above is still in the process of being developed. It has 
the advantage of being based on the already established OSI and TAFIM reference architectures. 
However, the question of whether the functional interfaces can be defined in enough detail and 
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generically enough to be able to produce a baseline model that supports all satellite control networks has 
still to be answered. 


DEGREE OF RELATED DISA SERVICE AREAS 

INTEROPERABILITY (Functions & Interfaces) 


D3 

MANAGEMENT & 
PLANNING ANALYSIS 
INTEROPERABILITY 


MANAGEMENT 

SERVICES 

i 

SPACE PLATFORM 
MANAGEMENT 
SERVICES 

PAYLOAD ? 

MANAGEMENT | 
SERVICES { 

ORBIT/ATTITUDE 

MANAGEMENT 

SERVICES 

i 

J 

CONTACT PLANNING 
SERVICES 

RESOURCE 

MANAGEMENT 

SERVICES 


SET OF 

INTERFACES THAT 
NEED TO BE 
STANDARDIZED 


SPECIFIC SETS 
OF STANDARDS 


INTERPROCESS 

STANDARDS 


D2 

CONTROL & CONTACT 

PROCESSING 

INTEROPERABILITY 



INTERPROCESS A 
INTERPRETATION 
STANDARDS 


Dl-b&c 

SPACE/GROUND AND 
SPACE NETWORK 
COMMUNICATION 
EXCHANGE 
INTEROPERABILITY 


I 

1 

6 PRESENTATION 
« * SESSION 
£ 4 TRANSPORT 
| * NETWORK 

2 DATA LINK 
1 PHYSICAL 


FUTURE 



f 


DATA 

: : ::: : ;:SPACe^W* : - 1:.'.::' 

: i: : EARTH/SPACE 


Space/Earth Link 
- OSI layer* 1&2 
• OSI Layer* 3-7 

Carrier Characteristics 

-up/down frequencies 

-accuracy 

-stability 

•polarization 

•bandwidth 

-signal strength 

ModfDemod Techniques 

etc. 


INTERPRETATION, 
PATH A LINK 
STANDARDS 


SGLS 

SDLS 

TBD 


D1-a 

GROUND NETWORK 
COMMUNICATION 
EXCHANGE 
INTEROPERABILITY 



INTERPRETATION, 
PATH A LINK 
STANDARDS 


Figure 6 MAPPING DEGREE OF INTEROPERABILITY TO SET OF STANDARD INTERFACES 


In the six months that this model has been applied to various situations, it has become apparent that some 
of the originally identified satellite control unique functions may be able to be defined as generic 
information systems functions in the future. On the other hand, some of the functions that were initially 
allocated to information systems are really process control functions and may have to use different 
standards than those selected for general information systems to meet the real-time response 
requirements needed. There are several related efforts ongoing and in each a satellite control reference 
model with standard terms and functional flows has proven to facilitate the analysis. 
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